The present invention relates to a method for graphic presentation of the results of tests of software programs, whereby the software program to be tested is composed of module building blocks and the software program can be presented in the form of a flowchart, and whereby a run protocol was produced in the test of this software program.
The development of software from existing software modules is preferred, when possible. Many sources of error are thereby avoided, since the individual, prefabricated software modules are already present in tested form and, thus, only the data flow and the correct operation of the interfaces of the prefabricated interfaces need be checked. A further simplification in the development is the employment of a graphic display that represents the data flow on the basis of a graph (for example, of a tree).
One possible application of this simplified software development is the development of services for an intelligent network (IN). An IN offers the possibility of offering a customer of telecommunication services further value-added services in addition to the voice and data communication. What are thereby involved, for example, are area-wide, uniform numbers, modified cost regulations such as xe2x80x9cfree phonexe2x80x9d or xe2x80x9cpremium servicexe2x80x9d, the recording of messages, etc.
These services must be adapted to the needs of the service vendor and the service user; they can be compiled in a simple way from individual, standardized software modules, which are referred to as SIBs (Service Independent Building Blocks).
The development of the services can take on an even simpler form on the basis of a graphic programming display (SD, Service Definition). The various modules (SIB) are thereby presented as symbols (icons) that can be connected in a tree-like or networked structure in a graphic. This structure can then be automatically translated into the runnable program (FSL, Flexible Service Logic), as which it is then to run in a suitable network element in the telephone or data network.
Before the new service can be applied, however, a test of the new service software (service logic) must be implemented. This occurs with specific testing methods that simulate various applications and co-log the result of the test run in what is referred to as a trace. The programmer must then manually check whether the result of the test is correct and whether the test checks the complete software.
Another possibility of error searching is comparison to the graph that represents the service logic. Whether all alternatives and, thus, all paths of the graph have been covered with the test can be more easily checked. This can be laboriously replicated on the basis of the representation of the service graph on the graphic service of the service definition (SD) tool.
A printout of the service graph is also often possible; this, however, can cover several sheets of paper, this in turn making the entire thing unsurveyable.
An object of the present invention is to provide a method with which the test of software can be more simply monitored. In particular, the inventive method provides a simple check to see whether the software to be tested has been covered as completely as possible by the test.
This object is inventively achieved in accordance with the present invention in a method for graphic presentation of results of tests of software programs for a realization of telecommunication services, said method comprising the steps of:
providing a software program for testing, said software program comprising a number of module building blocks;
presenting said software program in a form of a run graph, said run graph graphically presenting said module building blocks appropriately connected by connecting lines;
producing a run protocol during a test of said software program;
marking all test results of said test in a presentation of said run graph; and
marking those module building blocks and connecting lines of said run graph that were not traversed during said test.
A critical pre-condition of the inventive method is that the software program to be tested can be resolved into individual program modules. The program execution can then be simply presented as a graph wherein the individual program modules are connected to one another (by edges) in the run sequence. The graph can thereby assume a tree-like structure.
The presentation of this program run (referred to below as well as FSL, Flexible Service Logic) can be arbitrarily expanded, for instance by additional labels of the individual program modules (for example, with the name) and of the individual connections/edges (for example, with transfer parameters or with the result of a decision query).
A test run protocol (trace protocol) is produced in the test of the software program, this containing particulars about the course of the test, i.e. the reactions of the program to be tested to the individual test instances, for example to the respectively run software modules (SIB name).
Inventively, this trace protocol should now be automatically interpreted, and the modules and paths that have been run should be optically marked in the run graph.
Whether the tested program runs through the correct modules and thereby behaves correctly, i.e. arrives at the correct result, can thus not only be traced at the picture screen. On the basis of suitable markings, moreover, a check can be carried out as to whether the implemented test also completely tests the software program, i.e. all possible paths are run (path coverage).
The proposed method considerably simplifies the testing of newly created software programs, particularly for unexperienced testers or persons who are not as familiar with the program execution (for example, given separation of development and testing).
The laborious, manual interpretation of the test logs with the comparison of the trace log and the program execution that was previously necessary can be eliminated.
In an embodiment, there is provided a method for graphic presentation of results of tests of software programs for a realization of telecommunication services, said method comprising the steps of:
providing a software program for testing, said software program comprising a number of module building blocks;
presenting said software program in a form of a run graph, said run graph graphically presenting said module building blocks appropriately connected by connecting lines;
producing a run protocol during a test of said software program;
marking all test results of said test in a presentation of said run graph;
comparing said test results to an anticipated test result;
marking those module building blocks and connecting lines of said run graph that were incorrectly traversed during said test during said test; and
marking those module building blocks and connecting lines of said run graph that were not traversed during said test.
In an embodiment, a program path run during said test is marked on said run graph by graphically emphasizing connecting lines between module building blocks that were traversed during said test.
The present inventive method proves especially beneficial when the software to be tested was previously defined with a graphic development tool (SD) in the form of a run graph. For example, the individual program modules can thereby be arranged in the form of symbols (icons) and can be connected by module calls (arrows, directed edges of the graph). The result is a FSL source code that is imaged onto a runnable program with a translator.
This run graph can already be utilized for manual interpretation of the trace log in that the program was replicated on the basis of a printout of this graph or at the development display. The testing outlay is thereby in turn of the same extent in every renewed test run (regression test).
One possibility of marking is chromatic emphasis of the individual, used program modules and the paths run for that purpose (branches, edges of the graph). A complete test coverage is achieved when all edges of the program run data are colored, i.e. all program modules and all paths between the program modules were traversed. The application of various types of color (for instance, each test instance that is run is marked with a different color or the frequency of occurrence with which a specific path was run or the distinction between anticipated, i.e. correct, and faulty running of the run graph during the test) is at the discretion of the person skilled in the art. In addition to a different color type, a different line type (broken, bold . . . ) can identify the path employed.
This also enables the test implementation when no chromatic processing surface is available.
A test that is simple to implement and that is correct is extremely important particularly in the development of services for an intelligent network that has already been set forth. Once it was activated in the telephone or data network, the service logic must function extremely correctly, since this can otherwise harbor unpredictable effects and side effects on the entire network.
Since a redesign of services is very simple on the basis of the graphic design display, an equivalent display of a test tool should make this just as simple.
These and other features of the invention(s) will become clearer with reference to the following detailed description of the presently preferred embodiments and accompanied drawings.